Improvements in computer architecture have enabled a single computer to communicate with a large number of devices that are connected to the computer. To allow proper communication with each individual device, each device is typically provided with a driver. Drivers provide a means of communication between a computer and a device utilized by the computer, allowing access to functionality made available by the device.
A driver is required for each individual device to enable communication between the computer and the device. If each driver is written in a different manner, called by the computer in a different manner, and/or is executed differently, software programmers that utilize the drivers to enable access to functionality made available by the device would find it difficult to write device interactive software. Therefore, it is desirable to have a standard available to dictate a required manner of creating each driver thereby making the job of software programmers less difficult.
The VXIplug&play Systems Alliance was created on Sep. 22, 1993 to endorse and implement common standards and practices in both hardware and software. These common standards are utilized to assist device and software programmers and/or vendors in creating drivers to effectively communicate with devices and software. The alliance encourages the use of standard frameworks in the programming of device drivers, thereby enabling a variety of drivers from multiple manufactures and vendors to operate cooperatively within the same computer system. In addition, the use of the standard framework in the creation of drivers allows software developers and vendors to create programs that communicate with devices in a standard manner, thereby simplifying the creation of device-enabling programs.
VXIplug&play drivers make it easier for a programmer to communicate with different devices from different manufactures in a standard manner. It should be noted that while the present disclosure is provided with reference to VXIplug&play drivers, other plug and play drivers having similar characteristics such as, but not limited to, IVI-C drivers, may be replaced.
The use of a standard manner of communication necessitates programmer knowledge of one set of functions for programming devices that utilize VXIplug&play drivers. As an example, if a programmer intends to set a device to a known state, a specific function is called (i.e., reset). This function is the same function called by all devices that utilize VXIplug&play drivers regardless of the type of device utilized. Therefore, when setting any device that utilizes a VXIplug&play driver to a known state it is necessary to utilize and have knowledge of a single function. Alternatively, if there were no standard to utilize in programming device drivers, it would be necessary for a programmer to possess knowledge of each different function, for each different device, that may be used to set a device to a known state.
While the combination of efforts by the VXIplug&play Systems Alliance and the use of VXIplug&play drivers alleviates a certain amount of difficulty in creating programs that allow access to functionality made available by devices, there still is an amount of tediousness incorporated into device-enabling program creation. The following provides three examples of problems and/or limitations associated with the use of VXIplug&play drivers. It should be noted that these are not the only limitations associated with the use of VXIplug&play drivers, but instead, are merely used as examples.
First, VXIplug&play drivers comprise multiple functions that may be called during the creation of device-enabling programs by utilizing developing environments such as Microsoft Visual Basic. Unfortunately, functions made available by device drivers are presented to the programmer in a list that is not conveniently sorted. While the source of stored device drivers may be determined by use of a vendor unique identifier associated with defined functions of the device driver, the number of functions and constants defined by the device driver is still quite immense. Therefore, there is still a great amount of difficulty and/or tediousness involved in creating device-enabling programs since searches are required to find appropriate driver defined functions that may be used to call specific device functionality. This difficulty is amplified when more than one device is utilized, so that one program uses multiple devices.
Second, during the creation of device enabling programs, a handle is utilized to associate a device with a called function defined by the device driver. Specifically, when a programmer is encoding a device-enabling program, the programmer is required to manually identify the device associated with the function they wish to call during execution of the program. This process is tedious and requires searching to identify the handle used by the device for which they are providing programming. In addition, for each function that is called, the handle is specified to ensure that the proper device performs the defined functions.
Third, VXIplug&play drivers handle error reporting via the return of a value corresponding to error conditions that are defined by the programmer. Specifically, in creating device-enabling programs, the programmer is required to identify each possible error that may be encountered when calling functions of the device driver. In addition, the programmer is required to identify a path of resolution to be performed in response to encountering the defined error. As with identification of handles, identification of each error and resulting measures to be taken, is a tedious process.